What do you Review in Code? If you do code-review, what do you mostly do?

1. Look for patterns, explain them, report them everywhere or just somewhere and hope the other person will fix them all.
2. Discuss the design and why and what should be done about it.

Well, the 2nd cannot be automated, unless you’re able to put it in clear step-by-step, e.g SOLID laws in procedural code. So you still have to do that, sorry.

Dead Fat Code

But 1st step can be easily automated. How? Well, let’s take a dead code for example. In the last project I’ve helped to improve with Rector, there were 2 years of dead-code piled up. A dead that you have to:

• test
• maintain
• debug if broken
• review if changed anything related to it

So many human-hours wasted. In the end, we removed over 12 % of “dead fat code”. Wouldn’t it be better if that fat would never be got it?

Add Rector in CI in 3 Steps

1. Install Rector

composer require rector/rector --dev

2. Create rector-ci.yaml config just for code-reviews

# rector-ci.yaml
parameters:
    sets:
        - "dead-code"

3. And add to your CI bash

vendor/bin/rector process src --config rector-ci.yaml --dry-run

How to add Rector CI to your Favorite CI?

I’ve prepared a demo with PHP code and a testing pipeline for all widely used CI services.

• GitHub Actions
• GitHub + Travis CI
• Gitlab CI
• BitBucket

There you’ll find all the configuration you need to let your CI do code-reviews.

1. GitHub Actions [1]

# .github/workflows/php.yml
name: Rector Code Review

on: [push]

jobs:

    build:
        runs-on: ubuntu-latest

        steps:
        - uses: actions/checkout@v1

        - name: Validate composer.json and composer.lock
          run: composer validate

        - name: Install dependencies
          run: composer install --prefer-dist --no-progress --no-suggest

        - name: Code Review
          run: ./vendor/bin/rector process --config rector-ci.yaml --dry-run

2. GitHub + Travis CI [1]

# .travis.yml
os: linux
language: php

php:
    - '7.2'

install:
    # install composer dependencies for all stages
    - composer install --prefer-dist --no-ansi --no-interaction --no-progress

jobs:
    include:
        -
            stage: test
            name: "Tests"
            script:
                - vendor/bin/phpunit

        -
            stage: test
            name: "Code Review"
            script:
                - vendor/bin/rector process --config rector-ci.yaml --dry-run

3. Gitlab CI

# .gitlab-ci.yml
# inspired from https://docs.gitlab.com/ee/ci/examples/php.html

# see https://github.com/RobBrazier/docker-php-composer
image: robbrazier/php:7.2

before_script:
    # install composer dependencies for all stages
    - composer install --prefer-dist --no-ansi --no-interaction --no-progress

stages:
    - test

tests:
    stage: test
    script:
        - vendor/bin/phpunit

code-review:
    stage: test
    script:
        - vendor/bin/rector process --config rector-ci.yaml --dry-run

4. Bitbucket [2]

# bitbucket-pipelines.yml
# see https://github.com/RobBrazier/docker-php-composer
image: robbrazier/php:7.2

pipelines:
    default:
        - step:
              name: "Build"
              script:
                  - composer install --prefer-dist --no-ansi --no-interaction --no-progress

              artifacts:
                  - build/**
                  - vendor/**
                  - composer.json # beacause of scripts
                  - composer

        # @see https://confluence.atlassian.com/bitbucket/parallel-steps-946606807.html
        - parallel:
              - step:
                    name: "Tests"
                    caches:
                        - composer
                    script:
                        - vendor/bin/phpunit

              # Run Rector CI
              - step:
                    name: "Code Review"
                    caches:
                        - composer
                    script:
                        - vendor/bin/rector process src --config rector-ci.yaml

What sets to Start With?

Here are my favorite sets I apply first:

# rector.yaml
parameters:
    sets:
        - 'coding-style'
        - 'code-quality'
        - 'dead-code'
        - 'nette-utils-code-quality'

But you don’t have to stop there. Pick any of 103 sets that Rector provides. E.g.:

# rector.yaml
parameters:
    sets:
        - 'php70'
        - 'php71'
        - 'php72'
        - 'php73'
        - 'php74'

That’s it!

Oh… one more thing. You don’t have to resolve all the Rector reported flaws manually, just remove the –dry-run option and run it locally before pushing:

vendor/bin/rector process src --config rector-ci.yaml

Enjoy your coffee!

This article first appeared on Tomas Votruba’s blog: https://www.tomasvotruba.com/blog/2019/11/18/how-to-delegate-code-reviews-to-ci/